Electronic billing and payment (EBP) is widely available today due to the proliferation of the Internet and ubiquity of consumer computing devices. However, EBP acceptance by consumers has generally been by early adopters. The remaining members of the potential consumer base are aware of EBP, but have not yet availed themselves of the advantages of electronic billing and payment. Adoption of EBP has been split between biller direct scenarios and service provider (an aggregation point of EBP services) scenarios, each to be discussed in detail further below. There are barriers that, if addressed, can substantially increase the number of both consumers making up the EBP consumer base and EBP transactions, both in biller direct and service provider scenarios.
FIGS. 1A and 1B show current models of EBP services. FIG. 1A shows the Biller Direct model. FIG. 1B shows the Service Provider (SP) model. The Biller Direct model includes multiple electronic billers A′ through M′. Each of these electronic billers A′ through M′ maintains their own electronic billing enrollment and activation data, shown as databases 101 through 102. In the Biller Direct model enrollment and activation is a single process. A consumer 105 interacts with each of electronic billers A′ through M′ separately to begin receipt of electronic bills. Prior to enrollment and activation of electronic billing, each electronic biller A′ through M′ maintains information about each of their customers in databases 101 through 102. This is common information maintained by billers about customers. The consumer 105 must request to receive bills by providing enrollment and activation data, in addition to the information already maintained, to all electronic billers A′ through M′. Enrollment and activation data is provided via communications channels 106A through 106M. The consumer provided enrollment and activation data for electronic billers A′ through M′ is very similar, typically merely consumer identifying information such as the consumer's name, in addition to perhaps other consumer identifying information such as address, phone number, etc. It should be noted that at least some of this information is often merely confirmation of information the biller already has, as the enrolling consumer is, after all, already a customer. Thus, the consumer 105 ends up providing the same or similar data to each of electronic billers A′ through M′.
The provided consumer identifying enrollment and activation data for electronic billing can include any or all of consumer name, phone number, billing address, and perhaps a service address, depending on the type of electronic biller. In addition, a consumer 105 may be required to provide an account number with each particular electronic biller from which electronic billing is being activated. Some electronic billers require an enrolling consumer to provide identity confirming information that is not typically publicly known, such as social security number (SSN) or mother's maiden name. Many electronic billers require the same identity confirming information. It will be apparent that in enrollment and activation via the Web the consumer 105 has to access Web sites hosted by each of these multiple electronic billers A′ through M′ to provide enrollment and activation data at every single electronic biller Web site. Typically, the only different (unique) piece of information required by each electronic biller is the account number, because, as known, these differ by biller.
FIG. 1A also shows the consumer 105 enrolling for making on-line (electronic) payments to biller A′ through biller Z′. Enrollment is shown via communications channels 108A through 108Z. Enrollment for making electronic payments may be separate from enrollment for electronic billing in the typical Biller Direct EBP system. Required consumer supplied enrollment data for electronic payments is, here again, similar in nature among various electronic billers (payees), and typically includes funding account information. Each of electronic billers A′ through Z′ stores enrollment data for on-line payments in separate data repositories, 110 through 111, than those in which enrollment data for electronic billing is stored, 101 through 102. Typically, the enrollment data for making electronic payments is not linked to or otherwise shared with the enrollment data for receiving electronic billing, as shown by the separate electronic billing data repositories 101 through 102 and electronic payments data repositories 110 through 111. It should be noted that not all electronic billers offer electronic payments, and that not all billers offering electronic payments offer electronic billing.
In a Biller Direct model there are multiple ways that electronic payments can be performed. In one, an electronic biller A′ through Z′ provides all the functionality for completing the payment. That is, an electronic biller presents a user interface for payment via a communications channel 108A through 108Z, captures enrollment data for payments from the consumer 105, stores payment requests in data repositories 110 through 111, processes the payment requests, and issues all debits, credits, and remittance advice associated with payment requests.
In another way that electronic payments can be performed, a biller K′ through Z′ shares the functionality for completing payments. A biller outsources at least the actual payment processing and optionally also the payment user interface to a service provider, not shown in FIG. 1A. There are multiple variations as to whether the biller or the service provider captures enrollment data for payments and whether the biller or the service provider warehouses payment requests. In any event, a service provider processes the payment requests and issues all debits, credits, and remittance advice associated with the payment requests.
In enrollment for on-line payment, the consumer 105 typically provides, for each payee (billers K′ through Z′), customer name, customer address, phone number, and information identifying a funding account from which payment will be made. With some billers it is not necessary for a consumer to provide name, address, and account number information if that consumer is already enrolled for electronic billing. The consumer need only supply funding account information. This same information is required for payment to each payee. The different piece of information, among payees, as above, is the consumer's unique account number associated with each payee. In the Biller Direct model of FIG. 1A, the consumer 105 has to enter similar or the same data for every electronic biller, whether electronic bill receipt or on-line (electronic) payment is desired. Thus, existing EBP enrollment and activation processes are very redundant.
Accordingly, a need exists for an efficient enrollment and activation technique in the Biller Direct model of electronic billing and payment.
FIG. 1B shows an EBP model in which a service provider (SP) 120 is the primary connection for a consumer 115 to reach electronic billers and/or payees. This is known as a SP model. In the SP model enrollment and activation are separate processes. As shown in FIG. 1B, a consumer 115 communicates via communications channel 130 with a SP 120. The consumer 115 enrolls with SP 120, not individual electronic billers A through M. Shown from SP 120 are communications channels 142A through 142M to electronic billers A through M. Thus, one of the advantages for the consumer 115 in this model is that enrollment data is only entered once. Enrollment data is stored in enrollment database 135 by the SP 120. This core enrollment data includes the consumer's name and address and other key consumer identifying information. While the consumer 115 is only required to enter enrollment data once, the consumer 115 must enter activation data for electronic billing for each electronic biller. This activation data often includes part of, or even all of, the same data as required for enrollment.
Also shown in FIG. 1B are multiple instances of stored activation data 140A-140N. This reflects the fact that even though the consumer 115 has enrolled once with the SP 120, he or she is still required to activate receipt of electronic billing for each of electronic billers A through M separately. The consumer 115 has to enter activation data for each biller. Thus, for electronic biller A, consumer 115 is required to enter activation information such as social security number, mother's maiden name, etc. Further, consumer 115 has to continue to enter this information, or variations thereof, each time they activate a new e-Bill from a different electronic biller in this model. To begin activation, the SP 120 typically presents a list of all the billers for which the SP 120 presents bills. The consumer 115 selects those billers he or she wishes to activate and provides the required information for each. The service provider 120 then transmits an activation notice to each selected biller informing the biller to begin to provide bills to the SP 120 for presentment to the consumer 115.
In the SP model of EBP services the consumer 115 has the capability within one site to enroll for and review multiple electronic bills. This diagram also depicts a data store 150 associated with the SP 120 labeled “Other Subscriber Data”. This reflects the fact that consumer 115 can also access the SP 120 to pay billers other than electronic billers A through M, because this “Other Subscriber Data” includes payment data.
Different SPs offer one or more of at least three different payment models. A first is a ‘closed payee list—electronic biller’ model in which only electronic billers presenting electronic bills through a SP can be paid. That is, the only payees available are electronic billers. A second model is a ‘closed payee list—electronic biller and managed payee’ model in which electronic billers as well as payees with which the SP has a relationship can be paid. A third model is an ‘open payee list’ model. In an ‘open payee list’ model, consumers who enroll for EBP services can pay any payee.
Referring back again to the Biller Direct Model, as discussed above, consumers have to enroll in multiple places to make electronic payments and/or receive electronic bills. In addition to the problems discussed above, consumers have to remember which sites at which they have enrolled, as well as multiple site ID and password combinations. Because of different site requirements a consumer may not be able to obtain a desired ID/password combination. Also, a desired ID/password combination may be unavailable because it is already in use by another consumer. So, yet another barrier to the making of electronic payments and/or the receipt of electronic bills is that consumers have multiple Web sites they have to access to make payments as well as multiple Web sites to access to see bills and/or payment history. Each of these sites requires ID/password combinations. A consumer must have available the correct ID/password combinations upon each visit to a Web site.
One of the solutions to the problem of multiple user IDs and passwords is found in the on-line retail market. However, the solution only applies to electronic payments, not electronic billing. Today there is known a third party payment service provider which supplies payment services which are accessed via a payment link that is found in multiple Web sites operated by disparate on-line retailers. That is, multiple unrelated retail Web sites each have a link to a single payment service provider Web site. A consumer has to only enroll once for this third party payment service. The on-line retailers provide the link for the consumer to access this payment capability. Once the link is activated, the consumer's browser then is redirected to a third party hosted Web site in order to enter payment information.
In FIG. 2 are shown blocks 205A-205N, each representing one of multiple Web sites a consumer could go to make payments using this third party payment service. Shown are an auction Web site 205A, a retailer A Web site 205B, retailer B Web site 205C, retailer Web site C 205D, and a Web site of the third party payment service provider itself 205N. At each one of these Web sites 205A-205N there is a payment link 210A-210N that represents the third party payment provider. Once activated by a consumer, the consumer's browser is redirected to a payment Web site 201 hosted by that third party provider and branded as the third party provider. Of course, with link 210N a consumer is already visiting a web site of the third party payment provider. The payment Web site 201 is not branded based on the site from which the consumer may be making a purchase, nor is any of links 210A, 210B, 210C, or 210D branded based upon the Web site at which each respective link is found. Once the consumer has entered payment information at the third party payment service provider, then it is up to the third party payment service provider to feed information associated with the payment back to a seller from which a purchase was made.
The third party payment service provider does provide a single view of all of transactions for a given consumer. The consumer can go directly to the third party payment service provider in order to see all of his or her payment history as well as make payments. This provides the same user experience no matter where the consumer is activating a payment link 210A-210N. However, it should be noted that the third party payment service provider only offers a closed payee list. That is, only certain payees can be paid, those having a business relationship with the third party payment service provider. This third party payment service has a one-time enrollment feature and the consumer uses the same user ID and password no matter the Web site from which the payment link 210A-210N is activated.
The third party payment service provider technique of FIG. 2 works well in the retail environment, however it does not work well for companies who feel their brand is very important with their customers and would like a user experience to be the same whether the consumer is viewing an e-bill at the company's site, or doing anything else from the company's site, including paying a bill or making a purchase. In order to have a branded environment today, there are isolated silos of EBP activity such that a consumer has to go to multiple sites and have multiple user names and passwords in order for entities to have branded environments and otherwise control the user experience.
A tension exists between providing biller branded environments and a user being associated with a single network user ID and password combination that is usable across various biller branded and unbranded sites. That is, a user, because of biller branding, might not realize that that he or she is already enrolled to access electronic commerce services, based upon an enrollment at a first biller branded site, when visiting a second site that may or may not be biller branded, and vice-versa. Additionally, the user may not have access credentials to log on from the first site, if, for example, such was assigned in a consolidated log on context from a second site and never provided back to the user.
FIG. 3 will be utilized to show problems arising from this tension. It should be noted that FIG. 3 is merely exemplary in that a consumer is shown accessing a biller site to view a bill, and then a payment functionality site to pay that bill. The first site could be one of many types of sites, as shown later in FIG. 11, at which content may be viewed or functionality accessed. The second site, to which the consumer is redirected, could offer any type of EBP functionality in support of the first site. That is, the consumer could access a first site to make a payment, and be redirected to a second site to complete the payment or view a bill. Also, the consumer could access a first site to view a bill, and be redirected to a second site to complete the bill viewing.
As shown in FIG. 3, a consumer 301 accesses electronic bills though individual biller Web sites using a Web-enabled client, most typically a Web browser 305. FIG. 3 shows two biller sites, site 307 associated with biller 1, and site 310 associated with biller 2. It should be noted that one or both could be biller direct sites, or a service provider could host one or both. In the example of FIG. 3, both Biller 1 site 307 and Biller 2 site 310 are biller direct sites. Whether biller branded or not, the consumer 301 must log on at each of Biller 1 site 307 and Biller 2 site 310 to view his bills.
In order to pay an electronically presented bill, each one of Biller 1 and Biller 2 “hands off” a user session to a payment functionality Web site 315 provided by a service provider to capture a payment request and to perform payment processing. In doing so, either of Biller 1 and Biller 2 may perform a “consolidated log on” to the payment functionality site 315 so the consumer 301 does not have to explicitly log on again. That is, a biller provides consumer-specific access credentials to the payment functionality site 315. Further, the consumer 301 may not even be aware of a handoff. Alternatively, a direct log on procedure may be utilized by either or both Biller 1 and Biller 2 where the consumer 301 actively provides access credentials (typically a user ID and password combination) to the payment functionality site 315. Direct log on is also known as explicit, or dual, log on.
More particularly, FIG. 3 depicts biller direct sites 307 and 310 in which a biller presents billing information, but payment processing is performed by a service provider which presents payment functionality site 315. At 1 the consumer 301 accesses the Biller 1 Web site 307 via the Web browser 305. Biller 1 presents an authentication screen prior to permitting access to at least billing information. The first time the consumer 301 accesses the Biller 1 Web site 307, the consumer 301 must go through the enrollment process to establish a Biller 1-specific log on ID/password combination in order to view billing information. In subsequent visits to the Biller 1 Web site 307, the consumer 301 merely has to log on by supplying the Biller 1-specific log on ID/password combination. After successful enrollment, Biller 1 presents billing information to the consumer 301 (via the consumer's Web browser 305). In association with this presentation is a link to payment functionality site 315.
When the consumer 301 selects the link to the payment functionality site 315 the flow shown at 2 is invoked. At 2, Biller 1 redirects the Web browser 305 to the payment functionality site 315. This “handoff” includes a number of parameters, typically including payment particulars to identify the source entity performing the handoff and often to populate a payment request screen. Also, for consolidation log on sites, additional parameters supporting the consolidated log on with the payment functionality site 315 are typically included, such as a signature of Biller 1 to indicate this handoff is truly coming from Biller 1 and can be trusted, and Biller 1-specific payment functionality site 315 access credentials for the consumer 301. These Biller 1-specific access credentials for the payment functionality site 315 could be the same as, or different than Biller 1-specific ID/password combination for the consumer to access the biller 1 site 307.
The first time handed off to the payment functionality site 315 from Biller 1, the consumer 301 must enroll in the payment functionality site 315. For direct log on, payment functionality site 315 access credentials, typically consisting of an ID/password combination, are created, typically by the consumer 301, to access the payment functionality site 315. Also typically, the ID/password combination is not shared with Biller 1 site 307 (the source site). For consolidated log on, payment functionality site 315 access credentials, which may consist of an ID/password combination, an ID, a digital signature, or another cryptographic token, are created, typically by the biller and included in the handoff. Also for consolidated log on, if Biller 1 does not supply Biller 1-specific payment functionality site 315 access credentials in the handoff, enrollment includes site 315 providing back to Biller 1 site 307 access credentials to be utilized in subsequent handoffs of the consumer 301.
The tension lies in that it is highly unlikely that, in a direct log on context, the consumer 301 will recognize the fact that previously established credentials associated with direct logon may be used when accessing the payment functionality site 315 from another associated biller direct (or even another other type) site. Furthermore, if the payment functionality site 315 is first reached via a consolidated log on from a biller direct site, the payment functionality site 315 access credentials typically are never provided back to the consumer 301. Thus, even if he recognized that he had previously enrolled with site 315, he would not have access credentials to supply. Accordingly, he would be forced to re-enroll. Thus, the first time the payment functionality site 315 is accessed, for instance from the Biller 1 site 307, the consumer 301 must go through a payment functionality site 315 enrollment process, which involves providing personal information, including funding account information, and beneficially going through an identity verification and/or credit verification process, sometimes referred to as validation.
In a consolidated log on context, after the consumer has initially enrolled with the payment functionality site 315, through the Biller 1 site 307, the consumer 301 is able to bypass log on processing during a Biller 1 site 307 handoff, and instead is presented with a payment request screen from the payment functionality site 315, thus providing a relatively seamless experience between the Biller 1 Web site 307 and the payment functionality Web site 315. In a direct log on context, the consumer 307 has to log on with his payment functionality site 315 credentials in a subsequent visit, but still experiences a Biller 1-branded look-and-feel to the payment functionality site 315.
At some point in time after the operations of 1 and 2, at 3 the consumer 301 accesses the Web site of Biller 2 through Web browser 305. Biller 2 also utilizes the payment functionality site 315, although the consumer 301 may not realize that. The interaction between the consumer 301 and Biller 2 is the same as described in 1 for Biller 1. The consumer 301 establishes a Biller 2-specific log on ID/password combination for accessing the billing information on the Biller 2 Web site 310. It is certainly possible that the consumer 301 is able to establish the same log on ID and password as was used for the Biller 1 site 307, but the Biller 1 and Biller 2 systems are distinct. As in 1, the consumer 301 selects a link to the payment functionality site 315, and Biller 2 hands off the user session to the payment functionality site 315.
In 4, the consumer-payment functionality interaction is similar to that depicted in 2. Thus, if the Biller 2 site 310 practices consolidated log on with the payment functionality site 315, the first time site 315 is accessed by the consumer 301 via Biller 2 site 310, the consumer 301 will not be recognized by site 315 because no payment functionality site 315-recognized access credentials will be included in the handoff from the Biller 2 site 310. If the Biller 2 site 310 practices direct log on, the consumer 301 may not realize that access credentials established earlier through Biller 1, assuming the Biller 1 site 307 also practices direct log on, can be used here. If the Biller 2 site 310 practices consolidated log on, the consumer 301 may not have the access credentials established earlier through Biller 1, assuming the Biller 1 site 307 practices consolidated log on, and additionally may not realize that such credentials could be used here, even if the consumer 301 did possess those access credentials. Hence, the consumer 301 proceeds to establish a second payment functionality site 315 account.
Even though Biller 1 and Biller 2 leverage the same payment functionality site 315 the consumer 301 will not be able to take advantage of this effectively if he is accessing the payment functionality site 315 through Biller 1's and Biller 2's biller-direct Web sites. He will most likely end up unnecessarily establishing separate payment functionality site 315 accounts for use with each biller. Siloing thus effectively extends from bill presentment through bill payment, as described above, even though the same payment functionality site 315 account could be used across sites. This has undesirable consequences, including the consumer 301 repeatedly providing the same enrollment information to the payment functionality service provider, the payment service provider maintaining a plurality of accounts associated with the single consumer 301, and the consumer 301 being unable to potentially see payment activity across multiple billers in an integrated fashion at the payment functionality site 315. It should be recognized that the payment functionality web site 315 discussed above could alternatively or additionally be supporting sites other than biller sites. Furthermore, Web site 315 could be a bill presentment functionality site providing bill presentment services on behalf of multiple billers. Further, the functionality provided by web site 315 could include both payment and billing functionality, in addition to other EBP functionality. All of the undesirable consequences, whether alone or in combination, do not lend themselves to the goal of greater adoption of EBP services.
Accordingly, a need exists for a technique of accessing EBP services in which a consumer can utilize a single account across multiple branded sites.